This invention relates generally to networking and more particularly to recognition of portion of a network packet at a network interface.
Networking software is difficult to construct. One reason for this difficulty is that the physical on-the-wire representation of a network packet is not the same as the logical structure of the protocol data carried by the packet. So, a programmer must write interface code, usually as low level C, that understands the grammar of a packet and also performs necessary byte-order and alignment adjustments. Also, domain-specific information about the packet structure must often be coded at multiple locations in the system. The implementation of interface code, therefore, becomes a cumbersome and error-prone process.
Networking code in a system must interface with bare hardware in a network device, and at the same time implement complicated real-time algorithms. Generally, low-level data manipulation requirements and an emphasis on high performance have limited the choice of an implementation language to C. As a result, the development, testing, and deployment of new protocols is typically a slow and expensive process.
Motivated by this problem, significant research and effort have been directed to the development of systematic software architectures and languages for constructing networking software, usually by addressing a specific aspect of the complexity of networking code. One approach tries to better express the modular structure and composition of protocol layers. Another approach tries to better express the reactive control within each layer. A further approach emphasizes the verification aspect.
An additional aspect of the complexity of networking code comprises the low-level processing that takes place at the interfaces between the wire representation of a network packet and the protocol code in a host machine. This low-level processing typically involves data marshaling and unmarshaling, and packet classification (i.e., filtering) based on values extracted from the wire representation. The commonality in these tasks is that their implementation must take into account the physical on-the-wire layout of the logical protocol data. To allow interoperability, the physical formats usually are independent of any given machine""s architecture. The physical formats typically pack data together as tightly as possible, to minimize the overhead per unit of actual content, for the header.
One can, for illustrative purposes, consider the interface tasks in a firewall implementation such as Linux (v2.0.32). The following Example 1 shows an abstracted form of code in Linux networking module (net/ipv4).
Example 1 first computes the starting address of an IP packet""s payload into the variable tcp, by adding the size of the header (field ih1) to the start of the packet. Example 1 then computes the offset of the present IP fragment into the variable offset. As will be understood by those skilled in the art, a long payload may be transmitted by IP as a series of IP fragments, each of which contains a segment of the original payload, and an indication of those offset of the segment in the original payload.
In Example 1, the macro ntohs converts a network byte order representation to the host byte order representation for a 16-bit quantity. If the protocol in the payload is TCP and the offset is zero (first fragment), Example 1 extracts the source and destination port numbers from the TCP header. Subsequent code (not shown) implements specific firewall policies based on this extracted and other information, as will be understood by those skilled in the art.
The style of programming interface tasks of Example 1 has several drawbacks. For instance, a programmer must explicitly encode the layout of an IP packet using pointer arithmetic and bit operations. Further, the programmer must explicitly encode, using conditionals, the correlation between the protocol field""s value of IPPROTO_TCP and the payload being a TCP packet. Also, the programmer must remember to convert, at all appropriate places, multi-byte numeric quantities between the network byte order and the host byte order. To put this burden in perspective, endianness related macros hton* and ntoh* appear together about 300 times in the net/ipv4 of the Linux implementation (v2.0.32). Each occurrence of such cumbersome programming, increases the possibility of coding error in offsets, sizes, correlations, or endianness.
As will be understood by those skilled in the art, interface tasks are pervasive in networking code. In the core protocol implementation, interface tasks occur in each layer of a protocol stack at input functions (such as ip_receive and tcp_receive for IP and TCP) and output functions (such as the corresponding ip_send and tcp_send). Interface tasks also occur in the implementation of increasingly important system services such as network monitoring, accounting, and security.
One example of such an implementation comprises a packet filter. A packet filter demultiplexes the incoming packet to a user-level process, depending on the filter specified by the process. Essentially, filter specifications parse the packet in the general style of Example 1. One notable difference from Example 1, is that filter specifications normally are byte-codes for the packet filter""s virtual machine. Furthermore, hierarchical packet formats exist in contexts other than Internet protocols, giving rise to similar interface programming problems.
The programming style of Example 1 also raises concerns with respect to software engineering. For example, the same information of how to parse a packet, is encoded at multiple sites in a system, when that information should ideally be factored out (the xe2x80x9cwrite oncexe2x80x9d principle). Moreover, there is no system-wide, formal description of the packet format. Instead, the packet format is hard coded at each instance of interface code. This disadvantageously precludes use of automated techniques (such as model-checking) for verifying an implementation of a protocol or service against a specification.
It would be desirable were xe2x80x9ctypesxe2x80x9d in a programming language employed to encode the description of a packet. For example, in the Standard ML programming language, one might tentatively express the logic of Example 1 using the code fragment of the following Example 2.
The syntax #field var in Example 2 comprises field selection from a record. The term on the left ofxe2x86x92 comprises a pattern, here matching the datatype TCP. In contrast to Example 1, the programmer in Example 2 need not explicitly interpret the wire format.
Although Example 2 simplifies one aspect programming, there are compelling reasons why protocol code is not written this way. First, marshaling and unmarshaling between the high-level data type and the wire format would be prohibitively expensive. Second, if a protocol layer needs to export a uniform, composable interface, one cannot assign a type to the payload because the set of possible data types that the interface must match, is unknown.
Turning to C code, C aggregate types (structs and unions) do not incur as high an overhead cost as Example 2 in terms of marshaling and unmarshaling between the high-level data type and the wire format. This is because in C, one can cast a void* buffer to any other pointer type, and vice versa. Nevertheless, software applications typically need to perform some adjustments before using a value as a primitive type, because of possible mismatches of alignment and byte order between a host machine""s format and the network format.
Unfortunately, the C-type system is inadequate for describing packet formats. For instance, protocol headers can contain fields whose size depends on the value of a previous field in the header. For example, the options field in an IP header can occupy between 0 to 40 bytes depending of the value of a previous field ih1 (header length). In addition, variable-size fields cannot be represented as static types (data structures whose memory can be allocated at compile time). Moreover, pointer-based data structures (such as linked lists) involve dynamic memory allocation, which would be too expensive to use in this context. Furthermore, the C-type system does not guarantee that the interpretation of a union will be chosen in accordance with the value of a discriminating field. For example, suppose one wishes to represent an IP payload as a union of TCP and UDP types (discounting modularity issues). If the protocol field in an IP header is set to the value 17, the C-type system cannot constrain the interpretation of the payload to UDP, as will be appreciated by those skilled in the art.
Thus, a need exists for an enhanced approach for preparation of a description of a network packet. Another need exists for enhanced preparation for recognition of a network packet at a network interface. A further need exists for enhanced employment of a description of a network packet. A need also exist for enhanced recognition of a network packet at a network interface. Yet another need exists for enhanced preparation of a representation employable for recognition of a network packet at a network interface. A still further need exists for enhanced allowance for determination of a type for a network packet at a network interface.
Pursuant to the present invention, shortcomings of the existing art are overcome and additional advantages are provided through the provision of preparation for network interface recognition of network packet portion with declarative notation for field thereof and constraint therefor.
The invention in one embodiment encompasses a method for preparing a description of a portion of a network packet. A representation based on the description is employable for recognition of the portion of the network packet at a network interface. There is employed, in the description, a declarative notation that describes one or more fields of the network packet. There is employed, in the description, a declarative notation that describes one or more constraints for at least one field of the one or more fields.
Another embodiment of the invention encompasses a system for employing a description of a portion of a network packet. A representation based on the description is employable for recognition of the portion of the network packet at a network interface. The system includes a compiler component that employs a declarative notation, for the description, that describes one or more fields of the network packet. The compiler component employs a declarative notation, for the description, that describes one or more constraints for at least one field of the one or more fields.
A further embodiment of the invention encompasses an article of manufacture. At least one computer usable medium has computer readable program code means embodied therein for causing employment of a description of a portion of a network packet. A representation based on the description is employable for recognition of the portion of the network packet at a network interface. There is also provided computer readable program code means for causing a computer to employ a declarative notation, for the description, that describes one or more fields of the network packet. There is also provided computer readable program code means for causing a computer to employ a declarative notation, for the description, that describes one or more constraints for at least one field of the one or more fields.